bugfix/CSTACK-154: Deletion of iscsi storage pool should not try to d…#47
bugfix/CSTACK-154: Deletion of iscsi storage pool should not try to d…#47piyush5netapp wants to merge 4 commits intomainfrom
Conversation
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
…ix/CSTACKEX-154
|
|
||
| try { | ||
| OntapResponse<Igroup> igroupResponse = sanFeignClient.getIgroupResponse(authHeader, igroupParams); | ||
| if (igroupResponse == null || igroupResponse.getRecords() == null || igroupResponse.getRecords().isEmpty()) { |
There was a problem hiding this comment.
| if (igroupResponse == null || igroupResponse.getRecords() == null || igroupResponse.getRecords().isEmpty()) { | |
| if (igroupResponse == null || StringUtils.isBlank(igroupResponse.getRecords())) { |
There was a problem hiding this comment.
This we need to do for all files across ontap foler. Can be taken up as code refactoring task.
sandeeplocharla
left a comment
There was a problem hiding this comment.
Overall it looks good
rajiv-jain-netapp
left a comment
There was a problem hiding this comment.
Let’s add a clarification here: the workflow should not attempt to delete SAN igroups during storage‑pool deletion. Our current approach relies on ONTAP automatically cleaning up the igroups during the final unmap operation, which should be sufficient and avoids redundant handling in the workflow.
Additionally, addressing Sandeep’s observation — while it is correct that a storage pool cannot be created without hosts initially, we should consider a downstream scenario. For example, if a storage pool is successfully created and, at a later point (day‑N), the associated hosts become unreachable or are removed, do we end up retaining a stale storage‑pool entry in CloudStack?
This is something we can analyze and validate separately.
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
As said above replying Sandeep's comment, we have decided to not fail storage pool creation even if there is not host or host is not in appropriate state. This type of behaviour is followed by majority of storage vendor.Also, while creating igroup , we are setting delelte_on_unmap=true . This also answers the downstream scenario. |
…elete igroup
Description
This PR...
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Delete igroup call was not made to ontap . Checked through logs.
How did you try to break this feature and the system with this change?